Reading Time: 1 minutes
2021年2月~9月にみずほ銀行で発生したシステム障害について、金融庁と財務省は業務改善命令を出しました。
金融庁がみずほ銀行のシステム運用を厳しく監督し、共同管理するような位置づけとなります。
金融を司る機関である金融庁が、専門外である民間銀行のシステムに直接関与するのは異例なことです。
また、みずほフィナンシャルグループ(FG)とみずほ銀行(BK)の代表者を含む4名の役員が引責辞任したことも、障害の影響の大きさを物語っています。
金融庁が指摘したシステム障害の原因はなんなのか。
企業のシステム担当者がこの事象から学べるヒントはなにか。
金融庁やみずほが公表している資料をもとに、詳しく見ていきます。
2021年のみずほのシステム障害の概要
まずは2021年に発生した8件の障害を見ていきましょう。
日付 | 障害の概要 | 顧客への影響 |
---|---|---|
2月28日 | 定期性預金システムの「インデックスファイル」の使用率が100%を超過したことで、定期性預金に係る全ての更新取引が不能になったうえ、自動取消処理も不能となる「二重エラー」が発生し、ATM専用処理区画及びみずほダイレクト専用処理区画がダウン | 当該区画のATMが停止し、 ATM 内の通帳・カードが取り出し不能に |
3月3日 | データセンターのネットワーク機器が故障し、3分間通信が不安定に | 一部ATMでの通帳・カードの取込みが発生したうえ、ATM やみずほダイレクト(インターネットバンキング)で行われたナンバー ズ(宝くじ)の取引が一部不成立に |
3月7日 | カードローン商品のプログラムに不備があり、定期入金のバッチ処理時にエラーが発生 | ATMでの定期預金に関わる一部サービスが停止 |
3月12日 | 勘定系システム(MINORI) のストレージ装置内の通信制御装置が故障し、ストレージ装置とサーバーの間の通信が遮断され、同サーバー上の業務システムが停止 | 外国為替送金処理などが遅延 |
8月20日 | 営業部店端末制御用のDBサーバーの故障が連続して2台発生し、待機系のDBサーバーへの自動切替が動作せず、また必要な手順を踏まなかったために待機系への手動切替にも失敗 | 全営業店の端末及び店頭タブレット端末での取引業務が停止したほか、外為仕向送金の処理が遅延 |
8月23日 | BKメインセンター内のネットワーク機器が不安定化 | 一部のATM・ 営業部店端末等が一時的に使用不能に |
9月8日 | 取引共通基盤のディスク装置が故障し、他システムとの通信断が発生 | 一部のATM が一時停止 |
9月30日 | 外為送金取引に関わる統合決済管理システム(ISCS)においてにおいて、月末の集中処理に伴うシステム負荷の高まりによって処理が遅延 | 当日付の処理に間に合わない取引が発生したほか、一部の取引が、外為法で定められたアンチ・マネーロンダリング・システムによるチェックなしで実行される |
金融庁は上記の8件の中でも、顧客に大きな影響を与えた2月28日、8月20日の障害と、外国為替及び外国貿易法(外為法)違反を犯した9月30日の障害を特に強調しています。
2月28日の障害では4318台のATMが停止し、顧客のカードや通帳が5244件取り込まれました。
8月20日では、全てのみずほ銀行の営業部店で一時、店頭取引が行えない事態となっています。
最後の9月30日の障害では、処理遅延によって外為送金に関する一部取引が当日中に処理できない事態をおそれた経営陣が、マネーロンダリング防止用システム(アンチ・マネーロンダリング・システム)によるチェックを省略する判断を下しました。
このチェック無しでの外為送金が、外為法に違反したとみなされています。
金融庁が指摘した障害の原因とは
金融庁は、一連の障害を起こした直接的な原因として、以下の3つを挙げています。
開発や障害対応における品質を確保するための検証の不足
2月28日の障害は、勘定系システム「MINORI」の定期性預金システムにかかる、データベース管理システム(DBMS)がダウンしたことが問題の契機となりました。
そのうえシステムのアプリケーションにバグがあったために、他のシステムまで含む大規模な障害に発展しています。
事前の検証が十分に行われていれば、このような問題点に気づけた可能性もあります。
ただ残念ながら、みずほでは検証が適切に行われなかったために、問題を発見できず、障害を起こす結果となってしまいました。
新基幹システム(MINORI)の保守管理態勢が未整備
システム保守・運用時の体制の不備にも問題がありました。
同じく2月28日の障害では、影響が長引いた一因として、アプリケーションの監視体制が未整備だったことが挙げられています。
事務所には担当者が常駐しておらず、休日に障害が発生した際は、通知を受けてから事務所に駆けつける流れとなっていました。
また、システムエラーへの対応でも問題が指摘されています。
当障害が発生した時点で、アプリケーションのエラーログを分析するためのシステムが存在しませんでした。
そのため担当者が時間をかけ、「生」のエラーログを一つ一つ確認するという、非常に手間がかかる作業を行っていたようです。
このような保守管理体制の不備が、障害を長期化させ、深刻な影響を及ぼす原因になったとされています。
危機対応時の態勢について、訓練や研修などによる検証が不足
第3の原因は、危機に対する訓練や研修についてです。
8月20日の障害において装置が故障した際、冗長化されているDBMSを待機系に切り替える手順書にミスがあり、正常に切り替えることができませんでした。
この手順書についても、事前にシステム障害対応訓練などを適切に実施していれば、事前に突き止められた可能性があります。
みずほ銀行では、地震発生時の参集訓練などには力を入れていましたが、システム障害が発生したときの訓練は実施していなかったようです。
こうした訓練や研修の不足が、障害の大規模化につながったと指摘されました。
原因の裏に潜む背景について
また、このような直接の原因の背景として、以下のようなものが挙げられています。
IT 現場の実態の理解不足
IT戦略に関する最高責任者であるCIO(最高情報責任者)には、人事畑出身でITに精通していない方が任命されていました。
その他、MINORIの保守運用に関わる人員は、ここ3年で70%近く削減されています。
これらの人事を行った結果、MINORIなどの運用体制が脆弱化していました。
障害の影響範囲が広がりにくい特性を過信し、安定稼働していると誤認
MINORIはサービス指向アーキテクチャー(SOA)を採用していました。
SOAは、システムを一つの塊とみなすのではなく「機能単位の部品」の集まりとする考え方のことで、障害などの影響が局所的になりやすい特性を持っています。
この特性があるために、みずほ銀行はMINORIでは連鎖障害が発生しにくいと考えていましたが、実際には大規模な障害が発生してしまいました。
また、金融庁は最後に、これらの背景の裏に潜む真因として、以下の4点を指摘しています。
- システムに係るリスクと専門性の軽視
- IT現場の実態軽視
- 顧客影響に対する感度の欠如、営業現場の実態軽視
- 言うべきことを言わない、言われたことだけしかしない姿勢
結果として顧客や社会に大きな影響を与えたうえ、外為法違反を犯すまでの問題に発展してしまいました。
これらの発表の要点をまとめると、主にシステムに関わる「事前の検証」と「障害発生時の対応策」が不足していたと言えます。
システム障害を防ぐためには
みずほの役員が引責辞任したことからも分かるように、今やサービスに関わるシステム障害は会社全体の業務に深く関わり、ときに経営層の責任にもなりえます。
多くの業務がITシステムに依存している中、企業はみずほ銀行を反面教師として、自社のシステム運用体制を見直すべきです。
一連の障害から分かる障害を防ぐヒントを考えていきましょう。
ガバナンス面
まずはガバナンス面の問題から見ていきます。
金融庁は、「システムに係る専門性やリスク、IT現場の実態の軽視」を問題の真因にあげています。
みずほ銀行の経営層は、MINORIを含むITシステムの障害が顧客に与える影響を軽んじていました。
そのためCIOの人事や組織体制が脆弱となり、検証や危機対応が満足にできない事態を引き起こしています。
これは決して他人事ではありません。
現状、ほとんどの企業では、IT人材が大きく不足していることが判明しています。
一例として経営層のIT知識に関する調査を見ていきましょう。
情報処理推進機構(IPA)が2020年に行ったDXに関する調査によると、DXに取り組んでいるユーザー企業において、役員の内、IT分野の業務が分かる役員の割合は「0~2割」が75.4%、「3~6割」が18.5%、「7~10割」はわずか6.2%となっています。
IT人材やITリテラシーの不足は、みずほ銀行のような脆弱なシステム管理体制の要因となります。
ITシステムが及ぼす影響を正しく認識し、デジタル人材を育成することが必要です。
システムの保守・運用面
続いて、システムの保守・運用の問題に注目しましょう。
みずほ銀行では、システムやアプリケーションの運用体制に大きな問題がありました。
顧客に大きな影響を及ぼした2月28日の障害では、アプリケーションのバグに事前に気づかなかったうえ、発生後もエラーログを効率的に分析する術がなかったために問題が長期化しました。
大規模なシステムやアプリケーションの問題に対し、手作業で対応することは非常に困難です。
このような分析については、アプリケーション性能管理(APM)と呼ばれるツールが有効ですが、みずほ銀行では導入していなかったか、もしくはうまく機能していなかったのかもしれません。
基幹システムを運用する際には、APMのようなツールをうまく活用して安定性を高めることが必要不可欠です。
障害に強いシステムを実現しよう
みずほ銀行は、一連のシステム障害によって大きな損失を被ったうえ、顧客やステークホルダーの信用を失いました。
デジタル技術の影響度がますます大きくなる中で、システムの安定稼働は今や経営責任と言っても過言ではないほど、重要な業務と言えます。
企業は顧客の期待に答えるため、絶えずシステム保守・運用体制を改善していくことが求められています。
みずほ銀行などの障害事例に学び、障害に強いシステムを実現しましょう。
あわせて読みたい記事
Applications Managerについて
Applications Managerはサーバー・データベースなどのWebシステムの一元管理を実現する低価格APMツールです。設定が簡単で、グラフやマップ表示で瞬時に状況を把握が可能です。
サーバー・Webアプリケーション監視について口頭で細かく聞いてみたい方は、お気軽に無料のオンライン相談にお申し込みください。
無料オンライン相談に申込む
IT運用管理に関する資料ついて
ゾーホージャパンでは、企業のIT運用管理に役立つ資料や動画を無料で公開しています。
ぜひこちらからご覧ください。
フィードバックフォーム
当サイトで検証してほしいこと、記事にしてほしい題材などありましたら、以下のフィードバックフォームよりお気軽にお知らせください。